17 Commits (e14aa37d5900685ba8b8d2f51a6b47cbb26fa24c)

Author	SHA1	Message	Date
Predrag Gruevski	0ea837404a	Only publish to test PyPI from the `_test_release.yml` workflow. (#12668) ... PyPI trusted publishing wants to know which workflow is expected to do the publish. We always want to publish from the same workflow, so we're making `_test_release.yml` the only workflow that publishes to Test PyPI.	11 months ago
Predrag Gruevski	321cd44f13	Use separate jobs for building and publishing test releases. (#12671) ... This follows the principle of least privilege. Our `poetry build` step doesn't need, and shouldn't get, access to our GitHub OIDC capability. This is the same structure as I used in the already-merged PR for refactoring the regular PyPI release workflow: #12578.	11 months ago
Predrag Gruevski	360cff81a3	Overwrite existing distributions when uploading to test PyPI. (#12658)	11 months ago
Predrag Gruevski	94f018f1ba	Support release-testing packages with dashes in their names. (#12654)	11 months ago
Erick Friis	e933212a3d	run poetry build in working dir (#12610) ... Was failing because was trying to build from root: https://github.com/langchain-ai/langchain/actions/runs/6700033981/job/18205251365	11 months ago
Predrag Gruevski	3c5c384f1a	Test-publish to test PyPI and separate jobs to limit permissions. (#12578) ... Before making a new `langchain` release, we want to test that everything works as expected. This PR lets us publish `langchain` to test PyPI, then install it from there and run checks to ensure everything works normally before publishing it "for real". It also takes the opportunity to refactor the build process, splitting up the build, release-creation, and PyPI upload steps into separate jobs that do not share their elevated permissions with each other.	11 months ago
Predrag Gruevski	95a1b598fe	Update to `actions/checkout@v4`. (#11951) ... We don't use any of the new functionality at the moment. Just making sure we don't fall back on versions and fail to benefit from new patches. This is an easy upgrade and it's always harder to upgrade across multiple major versions at once.	11 months ago
Predrag Gruevski	d21dd72d64	Upgrade CI workflows to poetry 1.6.1. (#11344)	12 months ago
Predrag Gruevski	9aaa0fdce0	Use unified Python setup steps for release workflow.	1 year ago
Predrag Gruevski	a1e89aa8d5	Explicitly add the `contents: write` permission for publishing releases. (#9617)	1 year ago
Predrag Gruevski	9f08d29bc8	Use PyPI Trusted Publishing to publish langchain packages. (#9467) ... Trusted Publishing is the current best practice for publishing Python packages. Rather than long-lived secret keys, it uses OpenID Connect (OIDC) to allow our GitHub runner to directly authenticate itself to PyPI and get a short-lived publishing token. This locks down publishing quite a bit: - There's no long-lived publish key to steal anymore. - Publishing is *only* allowed via the *specifically designated* GitHub workflow in the designated repo. It also is operationally easier: no keys means there's nothing that needs to be periodically rotated, nothing to worry about leaking, and nobody can accidentally publish a release from their laptop because they happened to have PyPI keys set up. After this gets merged, we'll need to configure PyPI to start expecting trusted publishing. It's only a few clicks and should only take a minute; instructions are here: https://docs.pypi.org/trusted-publishers/adding-a-publisher/ More info: - https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/ - https://github.com/pypa/gh-action-pypi-publish	1 year ago
Predrag Gruevski	a7eba8b006	Release on push to `master` instead of on closed PRs targeting it. (#9544) ... This is safer than the prior approach, since it's safe by default: the release workflows never get triggered for non-merged PRs, so there's no possibility of a buggy conditional accidentally letting a workflow proceed when it shouldn't have. The only loss is that publishing no longer requires a `release` label on the merged PR that bumps the version. We can add a separate CI step that enforces that part as a condition for merging into `master`, if desirable.	1 year ago
Predrag Gruevski	a03003f5fd	Upgrade CI poetry version to 1.5.1. (#9479) ... Poetry v1.5.1 was released on May 29, almost 3 months ago. Probably a safe upgrade.	1 year ago
Yuki Miyake	85a1c6d0b7	🐛 fix unexpected run of release workflow (#9494) ... I have discovered a bug located within `.github/workflows/_release.yml` which is the primary cause of continuous integration (CI) errors. The problem can be solved; therefore, I have constructed a PR to address the issue. ## The Issue Access the following link to view the exact errors: [Langhain Release Workflow](https://github.com/langchain-ai/langchain/actions/workflows/langchain_release.yml) The instances of these errors take place for **each PR** that updates `pyproject.toml`, excluding those specifically associated with bumping PRs. See below for the specific error message: ``` Error: Error 422: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} ``` An image of the error can be viewed here:  The `_release.yml` document contains the following if-condition: ```yaml if: | ${{ github.event.pull_request.merged == true }} && ${{ contains(github.event.pull_request.labels.*.name, 'release') }} ``` ## The Root Cause The above job constantly runs as the `if-condition` is always identified as `true`. ## The Logic The `if-condition` can be defined as `if: ${{ b1 }} && ${{ b2 }}`, where `b1` and `b2` are boolean values. However, in terms of condition evaluation with GitHub Actions, `${{ false }}` is identified as a string value, thereby rendering it as truthy as per the [official documentation](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif). I have run some tests regarding this behavior within my forked repository. You can consult my [debug PR](https://github.com/zawakin/langchain/pull/1) for reference. Here is the result of the tests: |If-Condition|Outcome| |:--:|:--:| |`if: true && ${{ false }}`|Execution| |`if: ${{ false }}` |Skipped| |`if: true && false` |Skipped| |`if: false`|Skipped| |`if: ${{ true && false }}` |Skipped| In view of the first and second results, we can infer that `${{ false }}` can only be interpreted as `true` for conditions composed of some expressions. It is consistent that the condition of `if: ${{ inputs.working-directory == 'libs/langchain' }}` works. It is surprised to be skipped for the second case but it seems the spec of GitHub Actions 😓 Anyway, the PR would fix these errors, I believe 👍 Could you review this? @hwchase17 or @shoelsch , who is the author of [PR](https://github.com/langchain-ai/langchain/pull/360).	1 year ago
Harrison Chase	2448043b84	bump and fix (#8441)	1 year ago
Harrison Chase	cddd8ae83d	update release yml (#8364) ... only do the step that tags and adds release notes if its langchain	1 year ago
Harrison Chase	f35db9f43e	(WIP) set up experimental (#7959)	1 year ago