9 Commits (67696fe3ba2494f65942c3e9dd302d58a6eab694)

Author	SHA1	Message	Date
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