The `lock` command is specifically designed to manage the lockfile, so
running it should take precedence over any "frozen" setting.
Besides that, "frozen" is not specifically designed as "lockfile cannot
be updated" but as "installation of gems should be prevented if gemfile
is not in sync with the lockfile".
The lock command does not install any gems and preserves the property of
the lockfile being in sycn with its gemfile, so I think frozen should
not influence it.
The current behavior is quite confusing when frozen is set. On an app
where rubocop can get lockfile updates
```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```
Completely silent, it makes you think that it has written the lockfile,
but still no updates.
In verbose mode, it gives a bit more information, but still confusing
and unexpected, and does not change the lockfile:
```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```
With this commit, it updates the lockfile as expected.
https://github.com/rubygems/rubygems/commit/1d501ae8ea
I couldn't find a cross-platform way to check "can I create this directory?"
So I removed that, and went back to the original simpler logic of
"if the directory is writable, use it."
https://github.com/rubygems/rubygems/commit/3aa86a56db
Although Ruby's hashes preserve the insertion order, the ordering of
method coverage results is inherently nondeterministic, because they
are collected using `ObjectSpace`.
This is also a preparation for removing not_used members from
STR NODE. Current codes work without node type check because NODE_STR
has not_used2 member corresponding to nd_next of NODE_LIST and
NODE_DSTR. However it causes problme once not_used members are
removed from NODE_STR.
This is a preparation for removing not_used members from STR NODE.
Once not_used members are removed from STR NODE, STR NODE is smaller than
DSTR NODE. Therefore allocate NODE_DSTR instead of reusing NODE_STR.
... because GCC 13 warns it.
```
In file included from class.c:24:
In function ‘RCLASS_SET_ALLOCATOR’,
inlined from ‘class_alloc’ at class.c:251:5,
inlined from ‘rb_module_s_alloc’ at class.c:1045:17:
internal/class.h:159:43: warning: array subscript 0 is outside array bounds of ‘rb_classext_t[0]’ {aka ‘struct rb_classext_struct[]’} [-Warray-bounds=]
159 | RCLASS_EXT(klass)->as.class.allocator = allocator;
| ^
```
https://rubyci.s3.amazonaws.com/arch/ruby-master/log/20231015T030003Z.log.html.gz
If these jobs have the same name, GitHub allows merging a pull request
as soon as one of these jobs finishes.
We want to wait for all these jobs, so we have to use different names.
Since we don't skip this result job on [DOC], it's okay to use a
templated variable for this name.
We've been using matrix jobs as required status checks. However, when
[DOC] pull requests are created, the matrix content and templated
variables are not executed, which results in changing the name of the
matrix jobs. Then required status checks are considered missing because
of the different names. So we can't merge [DOC] PRs right now.
This `result` is a known technique to check the composite status of
matrix jobs. https://github.com/orgs/community/discussions/26822
The `result` job is not only a non-matrix job, which doesn't have the
above problem, but also an independent job that is not skipped by [DOC].
`needs` works even if all dependent jobs are skipped, so this trick
works well.
This is also useful when we want to change the content of matrix. When
we change one, we usually have to update branches of old pull requests
so that they get newly required jobs. However, with this method, only
`result` jobs are required, so you don't need to update old pull
requests.
I still don't like the fact that now you cannot visualize which matrix
jobs are "Required", but this seems like the best compromise.
I check the s390s-linux/Ubuntu system and I found that MN threads
doesn't work with:
* function inlining (-O0 doesn't repro)
* Thread local specifier (`_Thread_local`.
With `pthread_get_specific works)
(it is not an issue of `__tls_get_addr()` written in thread.c)
* swap context with ucontext (coroutine/ucontext)
I couldn't find out what is the root cause of this issue but
disable MN threads to make CI healthy.
On some platforms, such as FreeBSD and Oracle Linux, symbols defined
in the crt0 setup routine are exported from shared libraries. So
ignore the symbols that would be exported even in an empty shared
library.
David Rodríguez
Ellen Marie Dash
Ellen Marie Dash
Nobuyoshi Nakada
Yusuke Endoh
yui-knk
Takashi Kokubun
Jun Aruga
Kouhei Yanagita
Samuel Giddins
Koichi Sasada
Alexandre ZANNI
tomoya ishida
git
Kevin Newton